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ABSTRACT 


Military leaders and first responders desire the familiarity of commercial-off-the- 
shelf lightweight mobile devices while operating in the environments of the modem 
battlefield and disaster sites. Both environments pose a significant challenge for 
command and control since they lack reliable or secure communication infrastructure. 
Routine and simple mobile information-sharing tasks become a challenge over the 
cumbersome and expensive radios currently available to first responders and the military. 
To fill this gap, there is a need for secure, well-connected, lightweight, and mobile 
handheld computing devices with simple and familiar interfaces. 

This research explores the current Department of Defense requirements for 
security, existing secure tactical radios, and mobile device technologies. Furthennore, we 
investigate if Android devices might provide a solution. Specifically, we investigate the 
promising technology of Wi-Fi Direct on Android devices to build a secure network 
using a homogeneous Wifi mesh. We find that mobile devices running Android 6.0 
API 23 cannot build a multi-hop homogeneous Wifi mesh without obtaining root 
pennission. We recommend two methods for overcoming this limitation. The most 
promising method involves embedded devices providing a secure, lightweight, and 
mobile infrastructure through a homogenous Wifi mesh. 
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I. INTRODUCTION 


Military and first responders desire to leverage the familiar lightweight 
commercial off the shelf (COTS) mobile devices while operating on the modem 
battlefield or disaster areas. These environments can sometimes lack reliable or secure 
communication infrastructure. In such situations, military and first responders must 
provide their communications infrastructure. Military radios are expensive and awkward 
in comparison to COTS mobile devices, and are limited in numbers because of high 
costs. This research explores how Android devices might meet the current Department of 
Defense (DOD) requirements for security and provide military and first responders a 
familiar and simple-to-use-device to communicate over which enables Command and 
Control (C2). In this chapter, we define the problem, state our objective, outline the scope 
of our research, explain the impact to the DOD, and describe the structure of our 
research. 

A. PROBLEM DEFINITION 

A substantial amount of study has been done to exploit the advanced capabilities 
of the latest mobile devices for a variety of purposes; the domain of mobile device secure 
communications in infrastructure-less environments lacks a comparable level of research. 
We define the infrastructure-less environment found on modern battlefields and disaster 
sites and describe the need for mobile devices in those environments. Further, we 
highlight related work that we plan to build upon for our research. 

1. The Infrastructure-less Environment 

Infrastructure-less environments arise from either an absence of communications 
infrastructure or the degradation or destruction of such infrastructure. For instance, in 
battlefield situations, an enemy may deny the use of the infrastructure resulting in a lack 
of trustable infrastructure. This harsh environment poses a significant challenge for C2. 
Military and first responders must provide their communications infrastructure as 
described in the next two examples. 
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The military executes long-range aerial insertion over 100 miles from friendly 
forces and must arrive at their destination with all needed resources. On many of these 
missions, it is prohibitive to bring heavy or bulky communications equipment to enable 
bandwidth-intensive communications. The cellular infrastructure either may not exist or 
cannot be trusted. Every member of the mission still must carry on with the task at hand 
and needs to effectively communicate with each other. They need to send messages to 
each other, share location information of friendly forces, mark enemy forces, mark points 
of interest, share images, and coordinate supporting forces. These everyday tasks prove 
challenging over expensive and restrictive tactical radios which primarily support voice 
communic ations. 

A similar example exists when first responders operate in disaster sites where any 
surviving communications architecture may be congested, unreliable, or insecure. 
Coordinating the rescue and relief team’s efforts would be significantly improved by 
robust communications capabilities. Each member of the response team should be able to 
send messages to others in the team, share location information, mark dangerous areas or 
points of interest, share images, and manage support. Similar to the military, these tasks 
prove challenging over handheld radios. 

As we see in these two examples, simple and routine information sharing tasks 
become a challenge over handheld radio technology currently available to first 
responders and military personnel. Modern battlefields and disaster sites share the same 
underlying problem of a lack of trustable high bandwidth communications infrastructure. 
Austerity in communications networks surprise personnel who are accustomed to 
working with light weight and portable mobile handheld computing devices in well- 
connected environments. 

2. Mobile Devices in Infrastructure-less Environments 

Current secure mobile solutions require extensive manual configuration of 
multiple secure tunnels over tenuous links or must be tethered to an expensive tactical 
radio to provide the secure communications link. Neither is practical on the battlefield or 
disaster sites where only rugged devices survive the harsh environment. Complex to 


2 



configure, fragile, and expensive solutions are not practical. Any solution to this problem 
must provide a durable or inexpensive to replace, well-connected, lightweight, and 
mobile handheld computing device with a simple and familiar interface. 

B. MOTIVATION AND RELEVANCE TO THE DEPARTMENT OF 

DEFENSE 

Military leaders desire to leverage the familiar lightweight COTS mobile devices 
while operating on the modern battlefield in which computing and communications 
infrastructure are either lacking or impaired. Significant efforts have been made toward 
realizing that goal, but secure connectivity remains a weakness for these devices. Without 
secure connectivity, these mobile devices are severely underutilized. This research 
aspires to support secure connectivity through providing a less cumbersome and more 
fault-tolerant method of encrypting mobile device communications. 

1. Data Needed in Austere Environments 

C2 involves sharing infonnation both up and down the chain of command. 
Commands include written directions, pictures of targets or areas of interest, diagrams to 
help explain the written directions, locations of key terrain. Control consists of a constant 
feedback between the commanding to the commanded. Control might involve voice 
communications, tables of information such as troop numbers and locations, a video feed, 
and damage assessments (containing pictures, videos, and text). A commander’s staff 
performs the critical process of distilling all of the data and information into useful 
knowledge to inform the Commander’s decisions. Rich media helps convey that 
information in easily digestible formats. Too much information turns into information 
overload and delays the Commander’s decisions, too little information and the 
Commander makes uninformed decisions, making timely, accurate information critical. 

2. Apps Needed in Austere Environments 

There are mobile applications being developed to make devices more useful for 
military and disaster relief missions. These applications assume a simple, fast, secure, and 
reliable communications link to operate. In an austere environment, those 
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communications links must be established by the friendly forces, in a manner that 
sustains the required tempo of operations. 

For this research, we distil the above into the following media types: pre¬ 
formatted text messages (small), free text (small), formatted text (small), pictures (large), 
mixed media documents (large), and video (huge). Our solution needs to handle all of 
these formats and allow collaboration apps to operate seamlessly. 


C. SCOPE AND BOUNDARY 


Our research focuses on how to meet the needs of the DOD through mobile 
devices that self-organize into a mesh network that securely forwards traffic utilizing 
Internet Protocol (IP) communications without relying on external wireless or cellular 
infrastructure. This research specifically investigates COTS Android mobile devices 
(phones and or tablets) and their ability to fonn self-healing routes over a Wifi mesh 
using NSA-approved encryption techniques. 


The following, while closely related to this research, will not be covered: 

• The distribution of digital keys and decision about which keys to trust—for 
this research we assume each device contains its private digital key and the 
public keys of all other trusted devices. 

• How to protect data at rest on a mobile device that meets the NSA’s 
encryption requirements. 

• How to provide a way for this mesh network to easily join or leave an existing 
infrastructure from that infrastructure’s perspective. 


D. 


THESIS ORGANIZATION AND OVERVIEW 


Chapter I| presents the subject of the research and provides scope to the problem 


and the research. Chapter II|, examines the encryption requirements for secure 
communication, then assess the current military radios that meet the security 
requirements, and finally we survey wireless technologies found in COTs devices and the 


mobile ad hoc network (MANET) concepts needed to interconnect them. Chapter III 
outlines our proposed design of an App that provides a secure MANET with embedded 


DNS. Chapter IV| , we explain the results of our work and specifically the limitations of 
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Android 6.0 (Marshmallow) API 23 impose on implementing a homogeneous Wifi mesh 
network of mobile devices. We then suggest alternative methods for building a secure 
mesh to overcome the limitations. Chapter V , summarizes and concludes our findings. 
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II. BACKGROUND 


To leverage commercial-off-the-shelf (COTS) products to overcome the austere 
communications of an infrastructure-less environment, we need to understand what 
factors impact the solution space. This chapter explores current security requirements, 
government contracted solutions, promising current COTS technologies, methods to 
build mesh networks, and current research into building mesh networks with mobile 
devices. 

A. SECURITY REQUIREMENTS 

Military and first responders need their communications equipment to provide 
confidentiality, integrity, and availability (Hammond, Davis, & Gibson, 2015). The 
Department of Defense (DOD) requires all classified National Security Systems (NSS) 
conform to the National Security Agency (NSA) Type 1 Certification (Department of 
Defense, 2009). To simplify the process of integrating modern commercial security 
solutions, the NSA created the Commercial Solutions for Classified (CSfC) program 
(Hammond et ah, 2015; National Security Agency, 2016c). To protect those commercial 
systems, the NSA mandates use of the Commercial National Security Algorithm Suite 
(CNSA) (National Security Agency, 2016b). In the next three subsections, we look into 
each of these requirement sets. 

1. Type 1 Encryption 

Type 1 certified encryption equipment utilizes approved NSA algorithms. The 
NSA endorses it for securing classified and sensitive NSS information (Department of 
Defense, 2009). Type 1 devices must be handled as classified or as Controlled 
Cryptographic Items (CCI) (National Security Agency, 2003). CCI, while unclassified, 
still requires strict physical control measures to protect against loss or compromise 
(National Security Agency, 2003). 
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2. 


Commercial National Security Algorithms (CNSA) 


Per the NSA’s Information Assurance website, Commercial National Security 
Algorithm Suite (CNSA) now replaces Suite B for mandating commercial cryptographic 
algorithms for protecting the NSS (National Security Agency, 2016b). The main reason 
for this change comes from the advancement in quantum computing that rapidly breaks 
all traditional cryptographic keys. The NSA built the program to transition to quantum 
resistant algorithms, which are in the process of development. Until the new quantum 
resistant algorithms are available, the program continues to rely on the Suite B 
algorithms: Advanced Encryption Standard (AES) for information protection. Elliptic 
Curve Diffie-Hellman (ECDH) for key establishment. Elliptic Curve Digital Signature 
Algorithm (ECDSA) for digitally signing. Secure Hash Algorithm (SHA) for creating an 
information fingerprint or hash (Hammond et ah, 2015; National Security Agency, 2015). 


Table 1| provides an overview of the requirements to protect Secret and Top Secret 
information. 


Table 1. CNSA Requirements for Classified Information. Adapted from 

National Security Agency (2015). 


Classification 

Level 

AES 

ECDH 

ECDSA 

SHA 

Secret 

AES-128 

256-bit ECDH 

256-bit ECDSA 

SHA-256 

Top Secret 

AES-256 

384-bit ECDH 

384-bit ECDSA 

SHA-384 


3. Commercial Solutions for Classified Program 

To simplify the labyrinth of regulations and meet mobile mission objectives, the 
NSA created the Commercial Solutions for Classified (CSfC) Program (National Security 
Agency, 2016c). The program offers capability packages each describing different ways 
to layer commercial solutions (chosen from a pre-approved Component List) to protect 
classified NSS information while also allowing remote sites, phones, laptops, and tablets 
to securely and wirelessly connect to a secured infrastructure (National Security Agency, 


2016d). [Figure l| provides a simple example of how they might integrate. 
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Depicting Red, Gray, and Black Networks layered together to allow an End User Device to connect over a 
wireless connection securely. 

Figure 1. Example of Layered Security Solution. Adapted from 
National Security Agency (2016a). 


These packages describe Red, Gray, and Black Networks. The Red network refers 
to networks that contain the Enterprise Services and carry unencrypted classified or 
sensitive information. Red typically represents the unencrypted side of a sensitive data 
carrying system. The Grey network carries classified data encrypted in a single layer of 
commercial encryption (IPSEC, TLS, or SSH2). The Gray network also contains the 
Enterprise Mobility Infrastructure consisting of security mechanisms such as Intrusion 
Detection Systems (IDS) and Firewalls. The Black network carries the classified data 
twice-encrypted and consists of the wireless portion of the network. These networks are 
layered within each other (like an onion) with the Black network outside, the Gray 
network in the middle, and the Red network inside with the most protection (National 
Security Agency, 2016a). These colors do not indicate the classification levels; they 
merely indicate the state of encryption. Devices that access sensitive data must also 
provide at-rest encryption for stored data, anti-tamper mechanisms, strong authentication, 


and automatic-erasing mechanisms to stop brute-force attacks. Figure | provides two 
methods for handling security at the mobile device level. For the purpose of this study, 
we limit our focus to the data-in-transit aspect of the security requirements. 
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These two diagrams show how an EUD may implement the layered security to protect 
sensitive data. Both depict double wrapped sensitive data. The left diagram depicts two 
VPN tunnels bulk encrypting the applications’ data. The right diagram depicts an outer 
VPN encrypting the data which the applications already once encrypted. 

Figure 2. End User Device Solution Design. Source: 

National Security Agency (2013, p. 19). 


Of the available Capability Packages, the Mobile Access Capability Package and 
the Campus WLAN Capability Package provide the closest architectures applicable to 
infrastructure-less environments. In the following two subsections, we look at those two 
capability packages. 

a. Mobile Access Capability Package 

The Mobility Capabilities Package allows mobile devices to connect to an 
insecure public cellular network through double-layered security solutions to existing 
secured enterprise services (National Security Agency, 2013). This Package grew from 
the desire for Blackberry phones to connect to the classified enterprise and reflects the 
limited capabilities found in older mobile phones. It primarily focuses on providing 
traditional Blackberry phone features such as secure voice calling, secure email, and 
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access to secure websites. It focuses on how to link a Blackberry type phone to an 
enterprise by providing limiting controls to what the device can access within the Secure 
Enterprise. Figure 31 shows how these services might be configured to provide phones 
with access to the Secure Enterprise. A key part of this Capability Package’s security lies 
in the limitations it places on the services accessible to the mobile device. The purpose of 
this Package revolves around providing secure services to mobile devices. 


Cellular 

Network 



Mobility Black 
Infrastructure 
Management Servers 

Mobility Black Core 
Router/Switch 


Cellular 

Network 


VPN 

Gateway 


Mobility Black 
Network 


Mobility 

DMZ 

Border 

Firewall/ 

Router 


Mobility DMZ 
Infrastructure 
Management 
Servers 




SIP Server 


Mobility 
DMZ Core 
Router/ 
Switch 


Web Server 

Email Server 
AAA Server 


Mobility DMZ 
Network 


An example architecture that would allow an End User Device to connect to Secure Enterprise Services 
such as a Web Server, Email Server, or Secure Voice over IP (SVOIP or SIP) Server. 

Figure 3. Example Enterprise Mobility Infrastructure. Source: 

National Security Agency (2013). 


To create the required two layers of encryption, this Capability Package requires 
each Enterprise Service to provide encryption for its data and a bulk VPN tunnel to 


encrypt all of the traffic as depicted in [Figure 4.| If the End User Device (EUD) accesses 
classified data, then the encryption scheme must utilize CNSA for encryption. 
Additionally, each layer must operate independently, and implement Public Key 
Infrastructure (PKI) authentication of each layer to reduce the potential for compromise 
of sensitive data (National Security Agency, 2013). 
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This diagram depicts a mobile device connecting to government enterprise networks over 
double encrypted tunnels. Each service (voice and email) encrypts its traffic before the 
VPN tunnel also encrypts it. 

Figure 4. Two Layers of Encryption in the Enterprise Mobility Solution. 

Adapted from National Security Agency (2013). 


The Mobility Capabilities Package focuses on connecting traditional cellular 
phones to an enterprise network that contains sensitive data. The Capability Package 
provides security through limiting access to only specific services, hardening those 
services, and centralizing authentication, provisioning, and security mechanisms in the 
enterprise system. 


b. Campus WLAN Capability Package 

As its name implies, the Campus Wireless Local Area Network (WLAN) Package 
provides approved techniques for layering commercial security systems (from the 
approved list) to allow laptops, tablets, and smartphones to connect to an organization’s 
network wirelessly. Instead of a Blackberry-type device accessing limited enterprise 
services, this Capability Package provides a way to replace conventional stationary 
workstations with their mobile versions. 


This solution reaches the NSA’s required double encryption through Wifi’s 
WPA2 AES 128 encryption and enterprise Wifi management solutions as depicted in 


[Figure 5.| The inner layer of encryption comes from an IPSEC VPN using AES 256 
encryption. While this package provides LAN capabilities to mobile computing devices, 


12 




it still requires the network to protect sensitive services with firewalls and access control 
lists. 



Mobile device connecting to government enterprise networks over double encryption provided by 
wireless security and IPSEC tunnel. 

Figure 5. Campus WLAN Capability Package Example. Adapted from 

National Security Agency (2016a). 


The Campus WLAN Package requires the following algorithms protect all NSS 
up to Top Secret: IPSEC Encryption: AES 256; authentication and signatures: RSA 3072 
or ECDSA P-384; Key exchange: RSA 3072, DH 3072 or ECDFI P-384; and hashing and 
integrity: SFIA-384. Multiple Red networks of differing security levels may be part of 
this solution, but mobile devices should only connect to the enclave with corresponding 
classification level—Unclassified devices connecting to Unclassified networks, Secret 
devices with Secret networks, and Top Secret (TS) devices with TS networks. 

To protect the End User Devices (EUD), this Capability Package requires 
physical controls for protecting the devices commensurate with their classification level. 
For example, a Secret device must either be encrypted when at-rest or it must be 
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physically controlled as a Secret device. Figure 6| depicts how an EUD might implement 
these security measures. When powered on, it must be treated at the level of the material 
it is processing and on the screen. When powered down, its physical controls must protect 
it at the level of its at-rest encryption capability. 



How to set up two layers of encryption on the End User Device in the Campus WLAN Capability Package. 

Figure 6. Campus WLAN End User Device Diagram. Adapted from 
National Security Agency (2016a). 


This package focuses on connecting full-featured mobile devices to a network 
with two layers of security consisting of Wifi WPA2 and IPSEC VPN tunnels, as 


depicted in [Figure 5.| The security of this Package relies mainly on the enterprise 
protection capabilities. This Package provides a technology roadmap for the security 
requirements needed in creating a secure mobile COTS mesh. 


c. Commercial Solutions for Classified Summary 

The CSfC packages provide methods for securely connecting COTS devices to 
secure networks. The Mobility Capability Package focuses on how to connect the more 
traditional Blackberry-type mobile phone to secure enterprise services. The Campus 
WLAN Capability Package focuses on more full-featured mobile devices, such as 
laptops, tablets, and smartphones, allowing them to connect to classified networks 
wirelessly in a secure manner. To build an entirely COTs solution to overcome austere 
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communication environments, we need to leverage these CSfC packages. Specifically, 
the security requirements guide our choices in technologies with which to work. 

4. Summary of Security Requirements 

To effectively provide modern C2 systems in an infrastructure-less environment, 
we must understand the security requirements. NS A and the DIA together mandate 
Type 1 encryption accreditation, the CNSA algorithms, and CSfC packages as methods 
for protecting the NSS. The DOD currently requires Type 1 encryption devices to protect 
sensitive data. By de-facto the DOD also authorizes the use of CNSA and CSfC 
packages. Type 1 devices require rigorous testing which drives up their cost. COTS 
devices implementing CSNA and organized according to the CSfC package guidelines 
provide a significantly less expensive solution. Armed with a brief survey of Type 1, 
CNSA algorithms, and CSfC packages, we next examine a few of the communications 
solutions that match these accreditations and then a few technologies that might offer the 
promise of an alternate and less expensive solution. 

B. EXISTING TYPE 1 SOLUTIONS 

The majority of the current mobile infrastructure-less communications solutions 
center around military radios tethered to portable computing devices (a broader category 
than mobile devices). These radios excel in security, resilience, and reliability but falter 
in weight, bulk, and cost. Leveraging the Ultra High Frequency (UHF) and Very High 
Frequency (VHF) bands, they offer voice and low bandwidth data. To provide these 
links, they must either form direct radio links or indirectly connect through a repeater 
(Satellite Communications (SATCOM) repeaters, terrestrial repeater site, or airborne 
repeater). Voice communications require a wired handset or headset. Data 
communications require a laptop or mobile device to tether to the radio with an Ethernet 
cable, as wireless tethering is not currently approved (|Figure 7j ) The three radios below 
lead their class in this capability. 
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Connecting to SIPRNet via AN/PRC-117G. Source: U.S. Army, https://www.army.mil/ 
article/68498/Army_networking_radios_improve_communications_at_tactical_edge. 

Figure 7. Laptop Tethered to AN/PRC-117G 

1. AN/PRC-117G 

The Harris AN/PRC-117g provides secure voice and data communications over 
traditional UHF, VHF, and SATCOM channels. This radio contains the newest 
technology of the man-pack sized radios currently fielded (VHF, UHF, SATCOM 
channels using IW and ANW2 modes). One of its salient features is its ability to operate 
a secure Mobile Adhoc Network (MANET) using the proprietary Adaptive Networking 
Wideband Waveform (ANW2). Unfortunately, the AN/PRC-117G’s limitations are 
significant: Heavy (121bs), bulky (3.7 H x 7.4 W x 8.8 D inches), and expensive (over 
$30k per radio) (Harris Corporation, n.d.-a). Additionally, this radio must physically 
tether with a cable to whatever device requires its data capability. Another major 
limitation stems from ANW2’s utilization of Time Division Multiple Access (TDMA) to 
share the frequency band with all other radios in the MANET. Each additional radio in 
the MANET reduces the usable bandwidth, especially when establishing multi-hop 
networks. While the weight, size, and required cables detract from its appeal, the cost 
impacts its availability within the military forces, and even more so for first responders. 
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2 . 


AN/PRC-152 A 


The Harris AN/PRC-152A incorporates the advanced technologies found in the 
AN/PRC-117G into a much smaller form factor of 10.25 H x 3.0 W x 2.5 D inches with a 
reduced weight of 2.71bs (Harris Corporation, n.d.-b). Its reduced size and weight result 
in a limited power output of 5 watts (half that of the AN/PRC-117G), which limits its 
transmission range. It also suffers from the limitations of ANW2. At $ 13k per radio, it 
still requires a significant capital outlay to adequately equip relevant force structures 
(Department of Defense, 2014). 


RF-335M-STC 


The Harris RF-335M-STC (Figure 8)| extends the existing capabilities of the 
AN/PRC-152A. It adds the ability to operate on two separate channels simultaneously, a 
modular expansion pack, and a host of other powerful capabilities (such as the 16-Mbps 
MANET TrellisWare TSM-X protocol), all within in a smaller and lighter package 
(Harris Corporation, n.d.-c). Even with its impressive capabilities, this radio still requires 
a cable to connect a device to it. The United States Special Operations Command 
(USSOCOM) contracted Harris Corporation for these radios pending receipt of 
accreditation from NSA. 



Figure 8. The Harris Falcon III RF-335M-STC. Source: 

Harris Corporation (n.d.-c). 
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4. Summary of Modern Type 1 Devices 

The above devices provide secure and rugged capabilities to communicate in 
austere environments. Their cost prohibits issuing a device per first responder or military 
member. Additionally, the requirement to physically tether mobile devices to the radio 
adds undesirable weight and fragility to the solution. The next section explores the 
capabilities found in inexpensive COTS devices that might be leveraged to provide an 
alternate access architecture. 

C. EXISTING WIRELESS TECHNOLOGY IN MOBILE DEVICES 

This research seeks to explore whether or not the expensive military radios can be 
eliminated by directly connecting mobile devices together using their organic radio 
interfaces. For this to work, we must select approved mobile devices, with radio 
interfaces with enough range to enable dispersed devices to create links, and place these 
devices in a mesh network. Most mobile devices, on the CSfC Component List, support 
(in descending range order): 4G Long-Term Evolution (LTE), 802.11 Wifi, Bluetooth, 
Ant+, and NFC. The following subsections explore which transmitters most approved 
devices provide. 

1. 4G LTE 

While providing enough bandwidth (300 Mbps) and range (limited by line of 
sight) for connecting devices together in our desired mesh, 4G LTE requires cellular 
infrastructure to connect to other devices (Parkvall et ah, 2008). 4G LTE operates with an 
optional AES 128-bit or 256-bit encryption mode, which the operating network can 
disable (Bartock, Cichonski, & Franklin, 2015). It operates on Time Division Duplexing 
(TDD) and receives its timing from the cellular towers (Parkvall et ah, 2008). Since our 
task mandates an infrastructure-less environment, we do not further explore this 
technology. Future versions of LTE promise a technology called LTE-Direct. 
Unfortunately, LTE-Direct’s specification currently requires cellular infrastructure to 
provide timing for device interaction (Qualcomm, n.d.). 


18 



2 . 


IEEE 802.11 Wifi 


IEEE developed the 802.11 Wifi standard to enable devices traditionally found on 
a local area network (LAN) to connect wirelessly to form the LAN. It utilizes Carrier 
Sense Multiple Access with Collision Avoidance (CSMA/CA) to operate in either the 2.4 
GHz or 5 GHz ranges and provide up to 300 Mbps in version 802.1 In (Cisco, 2015). 
Version 802.11 AC bonds multiple channels together to allow up to 1.3-Gbps (Cisco, 
2015). The useable range of all modes depends heavily on the device’s power output, 
antenna, 802.11 protocol version, and environmental conditions. Higher frequencies 
(5 GHz) provide higher bandwidth but exhibit less range and greater attenuation by walls 
(Cisco, 2015). Lower frequencies (2.4 GHz) provide larger range and better penetration 
power through walls and other solids but at the cost of lower bandwidth (Cisco, 2015). 
Consumer reviews on relevant websites report an average indoor range of 150ft and 
outdoor range of 300ft. 

Wifi’s security modes are Open, Wired Equivalent Privacy (WEP), Wifi Protected 
Access (WPA), and WPA2. The Open mode provides no security and is not considered 
secure beyond a minimal level. WEP utilizes the Rivest Cipher 4 (RC4) stream cipher 
(IEEE Computer Society, 2012; Lackner, 2013). WPA utilizes the Temporal Key 
Integrity Protocol (TKIP), which shores up some vulnerabilities in WEP but still utilized 
the RC4 stream cipher (Lackner, 2013). WPA2 mandates the Counter Mode Cipher 
Block Chaining Message Authentication Code Protocol (CCMP) utilizing 128-bit AES 
standards (IEEE Computer Society, 2012; Lackner, 2013) and provides more robust 
security than other modes. 


Android devices provide two Wifi interfaces: wlanO and p2p0. The wlanO 
interface is used for standard Wifi operations and allows Access Control (Hotspot) and 
Infrastructure Mobile modes. The p2p0 interface is used for Wi-Fi Direct, detailed in the 


next subsection, and only operates when wlanO is in Infrastructure Mobile mode. |Figure 
^provides an overview of how Wifi and Wi-Fi Direct work together. 
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Figure 9. Android Devices Implementing Wifi and Wi-Fi Direct 


Wifi’s current edition (802.11 AC) defines one of four possible operating modes 
for nodes: Access Control, Infrastructure Mobile, Ad Hoc Mobile, and Mesh modes 
(IEEE Computer Society, 2012). 

a. Access Control 

Access Control mode, utilizing an access point (AP), allows other devices to 
connect to each other but only through the AP. Depending on the setup, the AP may 
provide network services such as Dynamic Host Configuration Protocol (DHCP), routing, 
and Internet gateway. This capability is typical of home wireless routers or commercial 
access point systems. 
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b. Infrastructure Mobile 

The Infrastructure Mobile mode allows devices to connect directly to a device that 
provides a Wifi AP through Access Control mode. This mode allows consumer devices to 
access Wifi networks and the Internet through wireless routers or commercial access 
point systems. 


c. Ad Hoc Mobile 

The Ad Hoc Mobile mode (Peer-to-Peer) enables devices to connect with each 
other without requiring any infrastructure directly. While the most basic mode available 
(IEEE Computer Society, 2012), it is rarely used due to poor standardization between 
devices implementing it (Griffith, 2009). Some early distributions of Android supported 
Ad Hoc mode with their devices. 

d. Mesh 

The Mesh mode creates a layer-two mesh where all joined devices operate in the 
same Internet Protocol (IP) subnet. Mesh mode provides both secure and nonsecure 
versions. Defined in 802.11s, Mesh mode has recently grown in popularity with Google 
Home Wifi (Google, n.d.), Plume Wifi (Plume Wifi, n.d.), and AmpliFi (AmpliFi Wi-Fi, 
n.d.) products. 


e. Wifi Summary 

Most Android and Apple IOS mobile devices support 802.11 Wifi in either 
Infrastructure Mobile (client device) or Access Control (“mobile hotspot”) modes. Since 
the advent of Wi-Fi Direct, described in the next section, those few Android devices 
dropped Ad Hoc for Wi-Fi Direct. Currently, only rooted Android devices with custom 
Wifi kernel modules support Wifi Ad Hoc or mesh modes (Wakelin, 2014). 

3. Wi-Fi Direct 

The Wi-Fi Alliance introduced Wi-Fi Direct in 2009 as an alternative to the 
poorly standardized implementations of 802.11 Ad Hoc (peer to peer) mode (Griffith, 
2009). Wi-Fi Direct builds on the advanced technologies of 802.11 AC to provide a 
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simplified process of discovering available peers or services and securely and 
automatically connecting to them (Monarrez, Singh, & Buettner, 2015a; Monarrez, 
Singth, & Buettner, 2015b; Wi-Fi Alliance, 2014). Wi-Fi Direct was designed 
specifically to simplify Ad-Hoc peripheral connections, not multi-hop architectures, as 
depicted in |Figure 1 0. It utilizes Wifi Access Control and Infrastructure Modes to build 
networks of devices. 




New P2P Device 



Existing P2P Device 



Figure 10. Adding a Device to P2P Group by Invitation. Source: 

Wi-Fi Alliance (n.d.). 


a. Operation Modes 

Wi-Fi Direct operates in three modes: Standard, Autonomous, and Persistent. 
These modes govern how Peer-to-Peer (P2P) groups are formed (Camps-Mur, Garcia- 
Saavedra, & Serrano, 2013). Only Wi-Fi Direct devices may act as Group Owners (GO), 
but either legacy 802.11 devices or Wi-Fi Direct enabled devices may join an existing 
group. The GO sets up an 802.11 Access Control mode AP for legacy devices to join. 

b. Security 

Wi-Fi Direct uses Wifi Protected Setup (WPS), seen mainly as push-button setup 
on modern routers (Wi-Fi Alliance, n.d.). Even though the push-button method of WPS 
shows significant security flaws (The H. Open, 2011), the Wi-Fi Direct software version 
omits the portions causing the security flaws. Since WPS utilizes WPA2-based 
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encryption for Transport Layer Security (TLS), the resulting network is as secure as other 
WiFi WPA2 networks. 

c. Addressing 

When Android version 6.0 acts as a GO, it utilizes the same IP subnet of 
192.168.49.0/24 for each network it establishes. The GO assumes the address 
192.168.49.1 and issues IPs via DHCP to the clients that join. Since all Wi-Fi Direct 
networks contain the same address space, a device can only associate to one Android- 
hosted Wi-Fi Direct network at a time (Funai, Tapparello, & Heinzelman., 2017). 

d. Routing 

On the Android versions of the implementation, Wi-Fi Direct does not add any 
routing statements to the routing table. Traffic originating from within the Wi-Fi Direct 
group must remain within the group. This design protects mobile devices from other Wi¬ 
Fi Direct connected devices exploiting their cellular data plans or connections to other 
networks but limits its ability to support multi-hop network architectures. 

e. Service Discovery 

Wi-Fi Direct utilizes service discovery messages built on the Universal Plug and 
Play (UPnP) protocol to broadcast beacon messages containing announcements about the 
services provided by its Wi-Fi Direct network. Wi-Fi Direct’s Service Discovery might 
allow a printer, television, or coffee maker to advertise its network and let nearby devices 
kn ow the services it provides (Camps-Mur et ah, 2013). This capability shows an 
interesting departure from IEEE’s Wifi, which traditionally views itself purely as a means 
to connect devices to the Internet. 

f Wi-Fi Direct Advantages 

Wi-Fi Direct provides a boon for home users and provides a couple of useful tools 
for our efforts in building mesh networks. Leveraging the power management features of 
Wifi Infrastructure and Access Control modes, it outperforms Wifi Ad Hoc networks in 
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power conservation (Wirtz, Heer, Backhaus, & Wehrle, 2011). Service Discovery also 
provides a useful method to identify other members of our mesh. 


4. 


Bluetooth 


Ericsson, a mobile phone manufacturer, originally designed Bluetooth to allow 
devices to connect to each other in a Personal Area Network (PAN) (Beachy, Gibson, & 
Singh, 2015). IEEE standardized Bluetooth as 802.15. Today, Bluetooth Special Interest 
Group (SIG) maintains the Bluetooth standard (Bluetooth Special Interest Group, 2014; 
Decuir, 2011). Bluetooth utilizes the 2.4 GHz band and creates channels using FHSS. 
Each channel supports seven slave devices controlled by a master device (eight devices 
per channel). The channel’s master device utilizes TDD and polling to synchronize 


communication with slave devices, as depicted in Figure 11| . Each slave may send data 
directly to the master (when polled) but not directly to each other, whereas the master 
may send data to all of the slaves at once (Beachy et ah, 2015; Bluetooth Special Interest 
Group, 2014). 
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Diagram depicts how a master controls the timing of a channel and 
how two slaves listen on that channel. 

Figure 11. Bluetooth Channel Time Division Duplexing Diagram. Source: 

Bluetooth Special Interest Group (2014). 
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Bluetooth version 2.0 introduced an Enhanced Data Rate (EDR), boasting a 2.1 
Mbps transfer rate. It also introduced FIPS-approved algorithms for encryption, including 
SHA-256, HMAC-SHA-256, and P-192 elliptic curve (Bluetooth Special Interest Group, 
2014). Bluetooth version 3.0 introduced high-speed (Bluetooth+HS) capabilities which 
allowed devices to negotiate with each other across Bluetooth and connect to each other 
using 802.11 for data transfer, providing a theoretical transfer speed of 24 Mbps. 
Bluetooth version 4.0 introduced the Low Energy (LE) specification for Internet of 
Things (IoT) devices operating on “coin” batteries (Bluetooth Special Interest Group, 
2014). Field testing of mobile devices using Bluetooth suggests an average throughput of 
almost 700 Kbps at a range up to 180 feet (Hammond et ah, 2015). Android devices 
currently support Bluetooth 4.0 (Samsung Corporation, n.d.). 

Bluetooth’s limited throughput and range limit its usefulness in building media- 
rich mesh networks. As mentioned by Hammond, Bluetooth may provide an excellent 
control channel or means to transfer text, but not an optimal means to transfer video or 
pictures (Hammond et ah, 2015). 


5. ANT+ 


Dynastream, a subsidiary of Garmin Ltd, created the proprietary, but open, ANT+ 
protocol to allow personal fitness sensors (master nodes) to transfer information to 
displays (slave nodes) with ultra-low power usage. An ANT+ slave node can capture 
multiple master nodes’ data. Multiple slave nodes can capture the same master node’s 
data (Dynastream, n.d.-b). The master nodes and slave nodes can be configured in any 
mix of many-to-many architectures, as seen in Figure ll (Khssibi, Idoudi, Van Den 
Bossche, Val, & Azzouz Saidane, 2013). 


Currently only supported by Android mobile devices, ANT+ operates up to 90 
feet on one of eight channels in the 2.4GHz frequency range, with one of three types of 8- 
byte messages: Broadcast, Acknowledgement, and Burst. Broadcast messages provide a 
stream of unacknowledged data. Acknowledgment messages provide critical data 
transmission that requires acknowledgment but uses more energy. Burst messages push 
20 kbps from master to slave, require acknowledgment, and consume even more energy 


25 




(Khssibi et al., 2013). ANT+ provides “8-byte network key and 128-bit AES encryption” 
(Dynastream, n.d.-a). 



Master and Slave 



(a) ANT+ Master node sending acknowledged messages to a Slave, (b) An ANT+ Master node pushing 
acknowledged messages to a Master/Slave node which also pushes acknowledged messages to another 
Slave node. 


Figure 12. ANT+ Example Topologies. Adapted from 
Khssibi et al. (2013, Figure 2). 


As a protocol designed for IoT devices, ANT+ provides excellent power 
conservation modes when in Broadcast mode but it fails to meet our needs in range, 
throughput, and device interoperability. So, for the purpose of our research, ANT+ is 
interesting but not usable in our mesh. 


6. Summary of Existing Technologies 

As we see, modem COTS mobile devices come equipped with a diverse range of 


communication technologies. In [Table 2|, we compare these technologies. To build an 
effective mesh, we need a technology that provides enough range and throughput to 
handle rich media. 4G LTE offers the best throughput and range except it requires 
cellular towers to control the timing of the protocol. ANT+ and Bluetooth offer excellent 
low power modes but do not provide the range or throughput needed. Thus, we focus our 
efforts on Wifi and Wi-Fi Direct. In the next section, we discuss how we might leverage 
these technologies to build different mesh networks. 
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Table 2. Comparison of Existing Technologies in COTS Mobile Devices 


Technology 

Outdoor 

Range 

Through¬ 

put 

Protocol 

Intended Use 

Security 

4G LTE 

20 miles 

300 Mbps 

OFDMA 

Cellular voice 
and data 

Optional 128-bit or 
256-bit AES 

Wifi 

300 feet 

300 Mbps 

FDMA Channels 
with CSMA/CA 
in channel 

Wireless FAN 

128-bit AES-based 
CCMP 

Bluetooth 

180 feet 

700 Kbps 

FHSS channels 
with Master- 
Slave TDMA in 
channel 

Wireless PAN 

SHA-256, HMAC- 
SHA-256, and P-192 
elliptic curve 

ANT+ 

90 feet 

20 Kbps 

Master-Slave: 
FDMA channels 
with TDMA in 
channel 

PAN IoT 

sensors 

8-byte network key 
and 128-bit AES 


Adapted from Bluetooth Special Interest Group (2014), Decuir (2011), Dynastream (n.d.-a, n.d.-b), IEEE 
Computer Society (2012), Khssibi et al. (2013), Parkvall (2008), Qualcomm (n.d.). 


D. TYPES OF MESH NETWORKS 

Meshes come in many different shapes and sizes. In this section, we present the 
difference between fully and partially connected mesh networks. We also present the 
difference between heterogeneous and homogeneous meshes and review the teeter-totter 
technique and how that might apply to our problem. 


1. Fully vs. Partially Connected Mesh Networks 

Meshes are classified into partially or fully connected meshes as depicted in 


Figure 13| . In the context of networking, each has different strengths and weaknesses that 


we will now examine. 
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Figure 13. Fully vs. Partially Connected Meshes 

A fully connected mesh implies that every node has a link to every other node. In 
a fully connected computer network, each computer can directly communicate to every 
other computer; the process of one node communicating with another node is simple. In a 
fully meshed Ethernet network, each computer would connect to all other computers with 
a dedicated Ethernet cable—requiring N*(N-l)/2 cables for N computers. In practice, 
fully connected meshes are uncommon since they do not scale well. As fully connected 
computer meshes grow, they quickly exhaust their access medium. In a resource- 
constrained environment, fully connected meshes are rare and impractical. 

A partially connected mesh contains at least some nodes not fully connected to 
every other node. In a partially connected mesh computer network, devices not directly 
connected send traffic to intermediary devices, which in turn forward the traffic to the 
desired recipient, thus fonning a multi-hop architecture. Most modern computer networks 
are a form of partially connected meshes, where multiple paths between nodes allow for 
some redundancy and survivability. Partially connected meshes trade the complexity of 
their routing algorithms for the conservation of the transport medium and scalability. 

The resource-constrained environment of the radio frequency (RF) spectrum 
generally, as well as the range constraints of line-of-sight radios, restricts wireless data 
networks to only partially connected meshes. For this reason, we only attempt to 
implement a partially connected mesh for our research. 
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2. Heterogeneous versus Homogeneous Mesh Networks 

Not only do we see the differences between fully connected meshes and partially 
connected meshes, but we also must consider utilizing different mediums in creating the 
mesh. Thus, we need to focus on homogeneous and heterogeneous meshes. 

A homogeneous mesh consists of similar nodes and similar li nk s. In a mesh 
computer network, this might mean that the computers are all laptops and the links are all 
Bluetooth. The benefit of a homogenous mesh comes from the simplicity found in the 
similarities. The devices do not need to maintain multiple interface types. On the other 
hand, it has the disadvantage of the entire mesh suffering if that medium suffers. 

On a heterogeneous mesh, the li nk s might be similar while the nodes may be 
dissimilar or the nodes are similar while the li nk s may be dissimilar, or both may be the 
case. A good example of this comes from the domain of the Internet of Things (IoT) with 
sensors and gateways (dissimilar devices) connecting into a heterogeneous mesh. A 
heterogeneous mesh also might consist of dissimilar links. For example, a computer mesh 
network might use Wifi and Bluetooth (Hammond et ah, 2015). A benefit of a 
heterogeneous mesh comes from its diversity. A weakness in one part does not 
necessarily affect all. This diversity also produces the disadvantage of higher complexity 
in managing and requiring nodes to support multiple connection types (Hammond et 
al„ 2015). 

For our research, we strive for the simplicity of homogeneous mesh networks. 

3. Teeter-Totter Technique 

Another novel approach to connecting devices is the teeter-totter technique. This 
method is used when a device or node can only connect to one other device at a time. To 
form a mesh, a device switches back and forth between connections with other devices to 
create the appearance of being connected to more than one device at a time. By analogy, 
this is like multithreading in a single processor system: it gives the illusion of multiple 
threads executing simultaneously. This method, while interesting, should be reserved for 
extreme situations since it proves very inefficient with large delays in the passage of 
information (Funai et ah, 2017). 
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4. Mesh Summary 

As we see in this section, fully connected meshes are impractical since they 
require links to all devices, which creates a significant overhead on the access medium. 
We also see that heterogeneous meshes are complex. For our problem, we attempt to 
build a homogeneous and partially connected mesh network. 

E. MANET ROUTING PROTOCOLS 

The two broad categories of MANET routing protocols are proactive and reactive. 
Proactive protocols provide quick answers to routing requests by actively maintaining an 
awareness of the entire network topology. Proactive protocols collect and maintain this 
information to continuously map the network which results in significant network traffic. 
Reactive protocols do not attempt to find routes in advance. Instead, they search on- 
demand. Searching on-demand reduces the maintenance overhead but increases the 
request response time. The following sections explore proactive and reactive routing 
protocols. 

1. Proactive Routing 

The proactive routing protocols actively attempt to populate their routing tables. 
This search could be accomplished by examining all nodes (using depth- or breadth-first 
search techniques) or by finding local nodes and exchanging neighbor information with 
them. A few of the most well-known proactive, table-based, MANET routing protocols 
are Dynamic Destination-Sequenced Distance-Vector (DSDV), Babel, and Optimized 
Link State Routing (OLSR) protocols. 

a. DSDV 

The DSDV routing protocol utilizes the Bellman-Ford algorithm to find the 
shortest path by measuring the hop count to a destination. Further, it keeps an updated 
table of all destinations in the network. Each node uses “even” sequence numbers to 
declare good routes and avoid loops. When a node receives a route from a neighbor, it 
only updates when the route’s advertised sequence number is higher than its version of 
that route. If the advertised sequence number is also odd, then it drops the route. When a 
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node detects a link loss, it increments that table entry by one, which ensures its neighbors 
drop the route. Signaling neighbors to drop the route avoids the count-to-infinite issue 
that plagues the Bellman-Ford algorithm (C. E. Perkins et ah, 1994). DSDV implements a 
settling time requirement to dampen radical routing fluctuations. 

b. Babel 

The Babel routing protocol also utilizes the Bellman-Ford algorithm to build a 
distance-vector routing protocol. Per Internet Engineering Task Force (IETF) Request for 
Comment (RFC) 6126 (Experimental), Babel borrows the slow convergence of DSDV to 
limit the duration and frequency of routing loops and black holes in unstable networks. 
Its limitations come from its periodic routing table updates which “generate more traffic 
than protocols that only send updates when the network topology changes” and its hold 
times for retraced network prefixes (Chroboczek, 2011). The Babel routing protocol 
shows promise for mesh networks that exhibit significant mobility but still require 
proactively established routing tables. 

c. OLSR 

Unlike the DSDV and Babel, the Optimized Link State Routing (OLSR) Protocol 
does not use the Bellman-Ford algorithm. It regularly floods HELLO messages to 
discover li nk s and floods topology control (TC) messages to broadcast link-state 
information throughout the network (Narra, Cheng, Cetinkaya, Rohrer, & Sterbenz, 
2011). A core concept of OLSR comes from the use of multipoint relays (MPRs). 
“MPRs are selected nodes which forward broadcast messages during the flooding 
process” (Clausen & Jacquet, 2003). Link state information is generated only by MPR 
nodes, thus minimizing the number of flooded TC messages in the network (Clausen & 
Jacquet, 2003). OLSR works best in a densely-populated mesh network that can take 
advantage of the MPRs to reduce the traffic load. 

2. Reactive Routing 

Reactive routing protocols do not waste the resources of maintaining a route 
lookup table. Instead, they discover the route on-demand. By discovering routes on- 
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demand, the reactive routing protocols save on overhead but pass on the cost to the user 
who must wait for the route to resolve before traffic can flow. A few well know reactive 
routing protocols include Ad hoc On-Demand Distance Vector (AODV) Routing and 
Dynamic Source Routing Protocol (DSR). 

a. AODV 

The AODV protocol calculates the Distance Vector on-demand. It uses HELLO 
packets to discover and track neighbors. Upon an unknown route request, AODV floods 
route requests (RREQ) to its neighbors containing a time-to-live (TTL). Each neighbor 
rebroadcasts the RREQ. The RREQ continues outward until the TTL expires or a node 
responds with a route reply (RREP) message. The RREQ messages contain sequence 
numbers to protect intermediate nodes from creating routing loops and also detennine the 
freshest path (highest sequence number). The node with knowledge of the destination 
sends a route reply (RREP) message back to the originator along the reverse path and 
forwards the RREQ to the destination so that it also knows the route. Every node along 
the reverse path records the new route for future use. If the RREQ does not find its 
destination, then the originator rebroadcasts it with a larger TTL and higher sequence 
number (C. Perkins, Belding-Royer, & Das, 2003). Note that the use of the reverse path 
implies that the protocol assumes bi-directional links throughout the entire network. 

b. DSR 

The Dynamic Source Routing (DSR) also uses a broadcast RREQ containing the 
source, destination, and sequence number to neighbors who forward the RREQ after 
appending themselves to the request. When the RREQ message reaches the destination, it 
contains the reverse path on which to send the RREP, also implying the demand for bi¬ 
directional links throughout the network. Maintaining a list of the nodes in the path 
protects against routing loops. The destination, intermediate, and source nodes cache the 
route and utilize it. When a link fails, each end of the failed link floods the failure to the 
network. Any node with a cached route that contains the link drops the route from its 
table (Johnson, Hu, & Maltz, 2007). DSR’s strengths lie in its ability to handle node 
mobility and network segmentation. 
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3. MANET Routing Protocol Summary 

In this section, we explored the common routing protocols utilized for MANETS. 
The two groupings of MANET routing protocols are proactive and reactive protocols. 
Proactive protocols provide a quick response at the expense of route maintenance traffic. 
Reactive protocols reduce the overhead of route maintenance but increase the time per 
request cost by adding the time for route discovery. Each protocol provides specific 
characteristics that make them strong in certain circumstances. For our highly mobile 
mesh, we utilize OLSR since it convergences quickly in response to routing requests. 

F. MANET DATA LOOKUP 

The infrastructure-less environment of MANETs removes the servers needed for 
centralized data lookups such as Domain Name Service (DNS), Structured Query 
Language (SQL), or Post Office Protocol (POP). These functions might reside in 
miniature fonn on mobile devices, but not in their centralized simplicity or power. By 
distributing these capabilities, it is possible to provide a fault-tolerant and aggregated 
implementation. Once distributed, each device must still have access to the disbursed 
capability. Finding data in this distributed system shares the same trade-off as we have 
seen in the proceeding section—proactive lookup or reactive search for content’s 
location. In data lookup, a proactive system creates a Structured Overlay and a reactive 
search is called an Unstructured Overlay. 

1. Structured Overlays 

Structured Overlays build on the idea of distributing a data structure across 

multiple nodes. Hash Tables are a popular data structure for distribution since they 

provide key->value lookups. Hash tables allow efficient data indexing for retrieval in 

0(log(n)) computational complexity. The challenge of this scheme comes from how to 

distribute the entries symmetrically, how to synchronize the overlay with the physical 

topology of the MANET, and how to provide resilience against node loss or network 

segmentations. To this end, the MADPastry protocol integrates a Distributed Hash Table 

(DHT) with AODV (Zahn & Schiller, 2005). Tightly grouped nodes (by hop-count) hold 

similar items. Each area of the MANET has a Landmark node which helps coordinate the 
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other local nodes and provides a touch point for nodes looking into that section of the 
DHT. A DHT provides a reliable method for overcoming the lack of centralized servers 
in an infrastructure-less network such as a MANET. 


2. Unstructured Overlays 

Setting up an Unstructured Overlay requires a shared Application Program 
Interface (API) to ensure all nodes share a common communication language to enable 
flood requests to continue to other neighboring nodes. Requests flood until an answering 
node responds with a result. Then, the answering node either sends the resulting data or a 
pointer to the data (address) back to the requestor. This system excels in small networks 
at finding common data (like hay in a haystack). Unstructured Overlays do not guarantee 
that something is found and do not perform well in large-scale ad-hoc networks where the 
volume of flooding requests can overwhelm the system’s capacity (Peterson & 
Davie, 2011). 


3. MANET Data Lookup Summary 

Both structured and unstructured data lookup have their place in distributed data 
systems. Structured overlays provide quick lookups of unique data (the needle in the 
haystack). Unstructured overlays provide low overhead and a simple way to find 
common or highly redundant data (the hay in the haystack). A distributed DNS server 
requires a structured overlay to ensure unique names are quickly available. We use a 
simple version of a DHT to provide DNS in our MANET implementation. 

G. RELATED WORK 

The field of using mobile devices to build a MANET has been subject of 
considerable and recent research. We intend to extend this body of work. This subsection 
provides recent and relevant research that we leverage. 

Hammond (2015) offer an overview of the military’s requirements for securing 
mobile devices. They survey the relevant regulations from the DOD, Defense 
Infonnation Systems Agency (DISA), National Security Agency (NSA), and its 
subordinate the National Infonnation Assurance Partnership (NIAP). 
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Beachy (2015) implement an Android Bluetooth messaging mobile application 
which utilizes a homogeneous mesh of Bluetooth connections to pass messages between 
Android devices. 

Monarrez, Singh, and Buettner (2015b) explore how to extend the Wi-Fi Direct 
protocol to allow for a “persistent communications network that involves zero user 
interaction.” Their extension provides an automated method for re-assigning the Wi-Fi 
Direct Group Owner (GO) without disrupting an existing Wi-Fi Direct group. 

Camps-Mur, Garcia-Saavedra, and Serrano (2013) evaluate Wi-Fi Direct on 
Android version 4.0 in a variety of configurations as it forms groups and provides power 
saving. We focus specifically on their work on building multi-group connections. 

Funai, Tapparello, and Heinzelman (2017) provide a method for building mesh 
networks on Android devices through obtaining root permissions and modifying how 
Android devices connects to other devices over Wi-Fi Direct. 

H. SUMMARY 

In this chapter, we reviewed the encryption requirements for secure 
communication, existing military solutions for infrastructure-less environments, wireless 
technologies found in COTs devices, types of meshes, MANET routing protocols, 
methods for storing data in a MANET we might employ, and existing work on the topic. 
The security requirements imposed by the military on their communication links establish 
a high bar. The solutions that meet that requirement are expensive and inconvenient. The 
device price must support large volume purchases for fielding to each first responder or 
military member. With this impetus, we investigate the built-in technologies of COTs 
devices for a means to connect them together in an ad hoc network with the potential of 
becoming a MANET. We also examined the different kinds of meshes that might be 
employed to build this MANET. Wifi with WPA2 encryption provides the needed 
security, bandwidth, and range to support this MANET. Out-of-the-box Android does not 
support mesh networks and Wi-Fi Direct’s restrictive addressing scheme limits devices to 
connecting to only one Android-hosted Wi-Fi Direct network at a time. So, in the next 
chapter, we explore how we might overcome Android’s limitations to build a Wifi mesh. 
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III. DESIGN 


In Chapter II we review the information requirements, security requirements, 
existing secure solutions, technologies modern mobile devices contain, different kinds of 
mesh networks, MANET routing protocols, and methods of storing information in 
MANETs without centralized servers. In this chapter, we explore how to build a 
homogeneous mesh network utilizing the technologies in an Android device. 


A. 


DESIGN OVERVIEW 


The Wifi’s well-established protocol, high bandwidth, and ubiquity within mobile 
devices make it a natural choice for building a mesh. Apple devices abstract Wi-Fi Direct 
under a multi-peer framework that makes forming a mesh nearly impossible. Since 
Android no longer supports Mesh or Ad Hoc Mobile modes, we look to Wi-Fi Direct as a 
method for building a mesh. A benefit of Wi-Fi Direct is its support for advanced power 


management and security features provided by Wifi Access Control mode. | Figure If and 


Figure 15| depict how we might connect Android devices together using their Wi-Fi 
Direct interface, p2p0, and Wifi Infrastructure Mobile interface, wlanO, to build a 
homogeneous Wifi mesh. The next section outlines in general terms our design for 
implementing this mesh. 



This figure shows an Android homogeneous wifi mesh network built using the Wi-Fi 
Direct interface and Wifi Infrastructure Mobile interface. Each line represents a 
connection from a wlanO interface to a p2p0 interface. The wlanO interface initiates the 
connection on the bi-directional communications link. 

Figure 14. An Example Heterogeneous Wi-Fi Direct and Wifi Mesh 
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This figure shows how the SINETapp configures the network stack. It builds a VPN which inserts the 
second set of layers 3-5 within the Application layer. This VPN allows the changes of the mesh to be 
seamless to the user level Apps. 

Figure 15. SINETapp Network Stack Flow and OSI Layer Connections 


B. 


DESIGN OF A SOLUTION 


Android devices contain all the fundamental technologies needed to create a 
meshed network. This section explores how to integrate these functions into an 
application. For simplicity, we refer to this application as the SINETapp and provide a 
generalized overview of the architecture in Figure 16j The SINETapp needs an “advertise 
and discovery” mechanism for finding other devices running the SINETapp. It requires 
an automated method of securely connecting to those devices. Once the SINETapp 
connects to other devices, it needs to act as a mesh router—discovering multi-hop routes 
to other non-neighbor devices and also forwarding traffic. To meet the security 
requirements outlined above in the Campus WLAN Capability Package, the SINETapp 
needs to encrypt all packets leaving the device. Either a proxy or a VPN interface 
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provides the second layer of encryption. Lastly, the SINETapp must provide distributed 
DNS capability. The following subsections describe each of these functions. 



Figure 16. SINETapp Application Architecture 
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1. ServiceManager Class 

The Service Manager class provides the switchboard from which the rest of the 
SINETapp functions. It runs in the background and maintains the application’s 
configurations. It waits until the User Interface initiates a connection intent and then it 
runs its Start method. The Start method calls the DiscoverService method from the 
Discover Class and the BuildAccessPoint method from the WifiConnection class. Once a 
connection has been made, the Service Manager calls Start from the VPN Connect 
runnable class. If the User Interface sends the Disconnect intent, then everything receives 
a disconnect call. 

2. Discover Class 

For devices to find each other, the SINETapp needs to share its availability. For 
this, we build a Java class that extends the Wi-Fi Direct Service Discovery Library. Our 
discovery class contains a DiscoverServiceLoop method and a RegisterService method. 
The ServiceManager class calls the DiscoverServiceLoop method. Once the 
WifiConnection class finishes the BuildAccessPoint method, the ServiceManager calls 
the RegisterService method. 

a. DiscoverServiceLoop Method 

The DiscoverServiceLoop method must operate asynchronously to ensure that it 
does not wait for other functions to complete. We call it with a pointer to a method as its 
argument. This pointer allows us to assign actions to perform upon discovery of another 
device. The particular action is outlined below in the WifiConnection class. The Wi-Fi 
Direct Service Discovery Framework only searches when requested, so we start a delayed 
(calculated by lequation T ) looping background thread that registers this Discover Service 
method with the framework. 

DiscoveryDelay = Constant x (Connected Devices + 1) + Random Integer [1-30] (1) 

The delay calculated in lequation l| sets how often a node should search for new 
networks with which to connect. The constant is 60 seconds. The randomized integer, 
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measured in seconds, helps reduce network flapping—avoiding all nodes becoming 
synchronized and making connection decisions at the same time. By multiplying the 
constant, also measured in seconds, by the number of inbound connections, a well- 
connected node evaluates its connectivity less frequently. For example, a node with four 
immediate neighbors will scan every 301 to 330 seconds. Since a lone or edge node has 
few connections, it assesses and attempts to connect more frequently. A lone node scans 
every 61 to 90 seconds. This weighted delay calculation stabilizes the topology by 
keeping central nodes more stable. The weight of the constant and span of the random 
integer need are chosen for the testing environment. Before application in production 
networks, they need research to provide optimization of energy consumption against 
detection delay. 

b. RegisterService Method 

The RegisterService method receives an object map containing free-text as an 
argument and registers it as a service with the Wi-Fi Direct Service Discovery 
Framework. This free-text contains the encrypted device name, availability number 
(calculated by |equation~2 ), SSID and key for the local Wi-Fi Direct GO AP (from the 
Automated Connection defined below). The Wi-Fi Direct Service Discovery Framework 
waits until it receives a discovery request and then responds with the free-text. 

Availability = device power [0-10] - number of connected devices (2) 

The Availability number comes from the device’s battery state translated into ten 
levels minus the number of connected devices. Equation 2 attempts to balance the battery 
state against the number of devices connected. We set the step size of the battery level in 
a variable to allow easy adjustment and “tuning” of this parameter. More than 10 devices 
connected reduces the availability to zero with the step size of 10. A low availability 
pushes detecting devices to diversify the mesh by connecting to a different node. 

c. Discover Class Summary 

The Discover Service method operates as the client, and Register Service method 
acts as the server. Together they allow devices to detect each other. 

41 




3. 


WifiConnection Class 


The WifiConnection class provides a BuildAccessPoint method and a Connect 
method. The ServiceManager’s Start method calls the BuildAccessPoint method first; 
then it calls the DiscoverServiceLoop method. The BuildAccessPoint method calls the 
RegisterService method and passes it the SSID and key. The DiscoverServiceLoop 
receives a pointer to the Connect method. Since we are using the Wifi interface, wlanO, 
for connections, each device may only initiate one connection to one other device. The 
Wi-Fi Direct interface, p2p0, only limits the number of inbound connections to the size of 
its DHCP pool of 253 addresses. This process builds layer 3 point-to-point links between 
each node. The relationship between nodes in the mesh is many-to-one. 

a. BuildAccessPoint Method 

The BuildAccessPoint method calls the Wi-Fi Direct createGroup() method. It 
then receives the Wi-Fi Direct GO AP SSID and key which it uses to call the 
RegisterService method of the Discover class. We configure the Wi-Fi Direct GO AP as 
a WPA2 pre-shared key (PSK) AP to provide the strongest encryption available. Wi-Fi 
Direct automatically assigns a pseudorandom SSID of the fonnat “DIRECT-XX-XX” 
and a random eight-digit alphanumeric key. Wi-Fi Direct also automatically chooses the 
Wifi channel to use. These are encrypted using the OpenSSL library and passed as an 
argument to the Register Service method of the Discovery class which allows other 
devices to collect the encrypted SSID and key. 

b. Connect Method 

The Connect Method receives the neighbor’s SSID and key in an encrypted firee- 
text packet. It decrypts the packet using the OpenSSL library to provide the SSID and key 
to the WifiConfig. Once configured it enables it and reconnects to it. By enabling and re¬ 
connecting, it allows the device to connect to the neighboring device’s Wi-Fi Direct GO 
AP. In the case of multiple neighbors, lequation 3| defines which neighbor with whom to 
connect. 

Priority = stranger? [0,100] + critical link [50,0] + signal [1-10] + availability (3) 
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In lequation 3,| we check the routing table to verify whether the detected device 
exists on the network already and add 100 to the equation in the case of new or isolated 
devices. We choose the value of 100 to provide enough weight to overcome other factors 
and ensure stranger nodes receive immediate attention. Next, we analyze the routing table 
to detennine if the link provides a single threaded connection to some part of the 
network. If a link supports a critical link in the mesh, then we protect that link against by 
providing it a heavy weight of 50. The signal strength comes from the local device’s 
detection of the other device. Availability comes through from the detected device in the 
encrypted package. All of these components are considered together to ensure isolated 
nodes receive priority, then critical paths are preserved, and lastly, energy conserved. We 
set the values of each component of the equation in variables to allow easy adjustment 
and “tuning” of parameters. 


c. WifiConnection Class Summary 

With the above Discovery and Automated Connection working together we can 
build the underlying layer of the mesh. Any lone device joins existing meshes. 
Segmented meshes heal due to the high priority assigned to connecting unrouteable 
devices. Devices with better signal strength and more battery-charge naturally become 
central to the mesh. 


4. RoutingDNS Class 

Once the SINETapp connects to other devices, it needs to act as a mesh router. It 
must discover non-neighbor devices for multi-hop routes. It also must correctly forward 
traffic along the path to the traffic’s destination. We implement OLSR, discussed in 
Chapter Ifl as our routing algorithm. In addition to OLSR, we built a method that takes a 
node pair as an argument and analyzes the network to determine if the link is critical. The 
routing table contains the DNS name and MAC address of each device. This modification 
provides essential functionality for the DNS service defined herein. 

The DNS aspect of this service allows devices to register themselves with other 

devices through the routing scheme defined above. When a device desires to find another 

device by name, it requests that device through the DNS protocol which queries the local 
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DNS server that in turn matches the request against the routing table. Domain names 
(such as http://www.google.com) that do not exist in the network cause the local DNS 
server to refer the request to a public DNS off-mesh. If the off-mesh DNS server is not 
accessible, then the request fails. 

SINET mesh’s namespace is of the format: [service].[devicename].sinet. 
[organization]. The service identity depends on the services a device provides and 
registers with the interface. User input, from the user interface defined below, defines the 
device name and organization. For example: www.micah-phone.sinet.nps.edu. 

5. VPNConnection Class 

To meet the security requirements outlined above in the Campus WLAN Capability 
Package, the SINETapp must interface with a VPN application to provide the second 
layer of encryption. The Android Developer API site provides the steps |(Figure 17)1 for 
using the VPNService class to create a VPN tunnel. We modify step 3 of the process by 
instead connecting to other neighbor nodes over multicast channels. For the VPN client’s 
network parameters, we set the following values: 

• Subnet: 10.0.0.0/8 

• IPv4 address: last three hex-tets of the MAC address converted to decimal in 
the fonnat of 10.XX.XX.XX 

• IPv6 address: by Stateless Address Auto Configuration (SLAAC) 

• DNS server: 10.0.0.1 

• default route: 10.0.0.1 

• For example, a device with the MAC address of C2:BD:D1:16:50:CD would 
result in the following settings: 

• IPv4: 10.22.80.205 

• IPv6: fe80::c2db:dlff:fel6:50cd 

The IPv4 scheme only ensures uniqueness with devices from the same 
manufacturer since we discard the vendor specific part of the MAC address. 
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All packets destined for 10.0.0.1 route to the closest device with an external 
network access; except packets sent to port 53 (DNS). Packets sent to 10.0.0.1:53 go to 
the method described in the RoutingDNS subsection which provides name resolution. 


1. When the user presses the button to connect, call prepare(Context ) and 
launch the returned intent, if non-null. 

2. When the application becomes prepared, start the service. 

3. Create a tunnel to the remote server and negotiate the network parameters 
for the VPN connection. 

4. Supply those parameters to a VpnService. Builder and create a VPN 
interface by calling establishQ. 

5. Process and exchange packets between the tunnel and the returned file 
descriptor. 

6. When onRevoke( ) is invoked, close the file descriptor and shut down the 
tunnel gracefully. 

Figure 17. Steps for Creating an Android VPN Tunnel. Source: 
https://dcvclopcr.android.com/refcrencc/android/nct/VpnScrvicc.html. 

For encryption, we encrypt outbound packet payloads using a symmetric key 
build by encrypting a pre-shared secret with the destination’s PKI-based Public 
asymmetric key. Inbound packet payloads are unencrypted using a symmetric key after 
decrypting the pre-shared secret with the recipient’s PKI-based private asymmetric key 
and injected into the VPNService’s interface. 

6. User Interface 

Since the purpose of this thesis is to provide a simple interface with intuitive 

configuration options, the SINETapp interface provides a simple interface consisting of 

text boxes to input the device’s name and pre-shared key, and green “connect” button. 

Once connected, the input fields become locked and the button changes into a red 
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“disconnect” button. A log screen, available from the menu, displays a trace of the 
device’s connection and routing activity to assist in troubleshooting. 

7. Summary of Design Overview 

The purpose of the SINETapp is to provide a simple-to-use application that allows 
mobile devices to connect to each other in a secure mesh that meets the DOD’s 
requirements for transmission security. Utilizing the service discovery methods and 
Group Owner methods of Wi-Fi Direct and the traditional Wifi Infrastructure Mobile 
connection mode we build the basis of a mesh network. Once the mesh is in place, we 
provide a hybrid routing and DNS system that allows devices to find each other with 
user-friendly names. To secure this mesh, we overlay a secure layer by implementing a 
peer-to-peer VPN using the VPNService interfaces. The result is a simple-to-use 
application that enables first responders or military members to communicate in an 
infrastructure-less environment. 

C. SUMMARY OF DESIGN 

This chapter provided a high-level overview of the design by which we intend to 
implement the security requirements through technologies organic to modern Android 
devices. We design a homogeneous Wifi mesh that supports MANET routing protocols 
and methods of storing DNS information in MANETs without centralized servers. In the 
next chapter, we explore the implementation of this design and our lessons learned from 
testing it on Android devices. 
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IV. IMPLEMENTATION AND TESTING 


In this chapter, we outline the fundamental and practical barriers obstructing our 
implementation of the SINETapp as laid out in Chapter III. We had hoped that Wi-Fi 
Direct would provide an energy efficient approach to building a mesh of Android 
devices. We find that the security and power features built into Android 6.0 
(Marshmallow), API 23, make it impossible to create a routable homogeneous Wifi mesh 


with Samsung Galaxy Note 4 mobile devices. In the Second half of this chapter! , we 


suggest two approaches to overcoming these limitations. The [first approach! requires root 


pennissions on the devices to modify the Wi-Fi Direct configurations. The |second 
method I takes an entirely different approach and builds the mesh on embedded devices, 
thus confounding the original intent of building the mesh entirely of homogenous COTS 
devices, that is, without non-organic communicating entities such as external radios or 
networking devices. Additionally, we evaluate the strengths of each approach. 

A. IMPLEMENTATION OF PROTOTYPE 

We follow the agile development model for developing up small pieces of code to 
validate capabilities before bringing the parts together into a larger construct. We develop 
modules of the SINETapp and concurrently test them by monitoring network traffic with 
wireless capture cards. This technique allows us to identify a few poorly documented or 
undocumented API “features.” This agile develop-and-monitor technique yielded the 


following results. We separate these results into three categories: [theoretical limitations!, 


practical limitations!, and positive results. 


1. Theoretical Limitations of the SINETapp Design 

Some of the limitations we found while implementing the SINETapp are 
fundamental to its design and not unique to the Android device’s vendor or Android 
version. These limitations are common across the majority of mobile devices or 


limitations imposed by the nature of the technology. We highlight frequency utilization 
and power consumption! as notable limitations introduced by the project’s design. 
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a. 


Frequency Utilization 


In our testing, we notice that Samsung Android devices (Galaxy Note 4 and 
Galaxy 6S) use Channel 6 when setting up a Wi-Fi Direct GO AP. Once the device 
configures and enables the GO AP, it blocks wlanO from connecting to any AP on any 
channel other than Channel 6. This limitation derives from the constraint that mobile 
devices contain only one Wifi antenna. If the device tried to monitor two channels at once 
with a single antenna, it would have to switch back and forth very quickly causing it to 
miss some packets. This limitation means that every device on the mesh network will be 


operating exclusively on Channel 6. Figure 18| shows our Kali Linux penetration-testing 
box running Airodump with an Alfa Wifi card to capture the wireless network traffic 
generated by SINETapp. 
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The Airodump result from three Android devices running SINETapp. The “CH” column indicates the 
channel each device is operating on. All three are using channel six. 


Figure 18. Airodump Results of Scanning SINETapp 


Since every link of the mesh runs on the same channel (a shared collision 
domain), as the network grows the quantities of collisions will also grow which drives 
down useful throughput. Hence, the network does not scale well. If the nodes of the mesh 
are tightly packed (geographically), the effect grows even worse as the added nodes 
compete for the limited resource of one Wifi channel. If geographically widely separated, 
the nodes might re-use the channel without colliding with each other. 

This limitation comes from SINETapp’s design constraint of building a 
homogeneous Wifi mesh out of mobile devices which generally only contain a single 
Wifi antenna. Using devices with multiple Wifi antennas or by switching to 
heterogeneous mesh network constructed with various interface types (Bluetooth and 
Wifi for example) would solve this limitation. 


48 





b. Energy Consumed Operating in Access Control Mode 

As we implemented and tested SINET we guessed that operating a Wi-Fi Direct 
GO AP would consume a significant amount of energy. We decided to informally test our 
hunch. Since it does not fonn a critical part of our research objective, we did not attempt 
to perform a rigorous energy consumption test. Specifically, this test lacks the controls 
and repetitions needed to provide scientifically reproducible results. 

Disclaimers: The devices used are the same model and age, but the battery 
capacity of both phones may not be the same. Further, we measured the battery level by 
reading the percentage reported by the device, which may be limited in its accuracy. We 
also only ran the test once in the configuration depicted in Figure 19. This test should 
only be considered interesting and not rigorous. 

With these disclaimers, we present a crude experiment to explore the general 
sense of energy consumption of Wi-Fi Direct. We hypothesize that operating an AP 
requires the hosting device to keep the Wifi card constantly “awake” to respond to 
BEACON messages and receive traffic from connected devices. Staying “awake” 
consumes more energy than “sleeping” the Wifi card between uses. 

To measure the severity of Wi-Fi Direct’s energy consumption, we set up a 
testbed according to [Figure 19l Nodes A and B start side by side with a full charge. We 
turn off all other apps and restart the both nodes. Once we verily both nodes are in nearly 
identical states, we load SINETapp. They exchange information with the other nodes in 
the testbed and set up their Wi-Fi Direct GO APs. We then disable the Wi-Fi Direct GO 
AP on Node B. We then connect Node A and B to Node E’s Wi-Fi Direct GO AP to 
simulate both devices connecting to the mesh. We connect Nodes C and D to Node A’s 
Wi-Fi Direct GO AP. On Nodes C and D, we run a continuous ping to Node A. For the 
first 40 minutes, we monitor Node A and B with their screens on which forces an 
“awake” state. We note that the “awake” state and screen consume significant energy on 
both devices. After the first 40 minutes, we turn off Node A and B’s display to further 
isolate the energy consumption of Node A’s Wi-Fi Direct GO AP. For the next 12 hours, 
we monitor the testbed by periodically waking Nodes A and B to verily their connectivity 
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to Node E. Keeping Nodes A and B connected to Node E, simulates a realistic outbound 
connection. At the end of 12 hours, we took screen captures of both nodes’ energy 


consumption history depicted in figure 20.| We combined the information into a single 
graph depicted in [Figure 21~ 


Node E (AP) 



Interfaces filled gray are inactive. Battery and plug symbols indicate power supply for 
each device. We measure the energy consumption of Nodes A and B to determine the 
energy required to operate a Wi-Fi Direct GO AP. Nodes C, D, and E stay awake while 
plugged into wall power to ensure their constant activity. 

Figure 19. Topology of Wi-Fi Direct GO AP’s Energy Consumption Test 


To calculate the results of energy consumed without the screen active, we focus 


only on the period of 40 minutes through 11.5 hours, shown in figure 21| . Node A, 
running the Wi-Fi Direct GO AP, consumed 68% of its battery energy in 10.83 hours 
equaling a rate of 6.28% per hour. Node B, during the same period, consumed only 5% of 
its battery energy equaling 0.46% per hour. This test suggests that an Android device 
running a Wi-Fi Direct GO AP, even with its screen off, consumes significantly more 
energy than a device not running the Wi-Fi Direct GO AP. 


Building a homogeneous Wifi mesh introduces the inherent energy cost of 
running APs on each node. With our design model, we must accept this energy cost. To 
avoid the energy cost would require that we change the nature of the mesh to a 

heterogeneous mesh. In the second half of this chapter, we suggest an alternate method 
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which removes this energy cost from the end-user mobile devices freeing them to 
perform only tasks that directly support the user. 
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The left-hand screenshot depicts Node A’s energy consumption history. The right-hand screenshot depicts 
Node B’s energy consumption history. 


Figure 20. Wi-Fi Direct GO AP’s Energy Consumption Screenshots 
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The dark blue area represents the power remaining in Node A while providing a Wi-Fi 
Direct GO AP. The light blue area represents the energy remaining in Node B in normal 
operation. 

Figure 21. Wi-Fi Direct GO AP’s Energy Consumption 
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c. Summary of Theoretical Limitations 

Our design of the SINETapp had to contend with the fundamental limitations of 
Wifi channel utilization and imposed a power consumption cost upon devices running 
APs. To overcome the issue of all devices operating on the same channel, we suggest 
multi-antenna devices or moving to a heterogeneous mesh. To overcome the power 
consumption issue, we suggest utilizing devices dedicated to operating APs. This 
approach, as with the use of a heterogeneous mesh, confounds the desire to utilize a 
single device per user-entity. These suggestions shape our alternate approaches later in 
this chapter. 


2. Practical Limitations of SINET’s Design 

While implementing the SINETapp, we also discovered Android API version 23’s 
specific limitations that may in the future be removed by Android software updates. 
These deficiencies include: how the Wi-Fi Direct DHCP server issues IP addressesj 


issues with IIPv4 unicast! on devices with redundant network routes, constraints with IPv4 


multicast! on Wi-Fi Direct interfaces, and limitations with [IPv6 sockets using SLAAC 


addresses. Below, we describe these limitations in detail and suggest methods for 
overcoming each. 


Since these restrictions exist as artifacts of the Android API version 23 
implementation, modifying Android’s source code might overcome the shortcomings. 
Unfortunately, this presents a challenging and time-consuming task that does not 
guarantee that Android’s source code curators will incorporate the changes into the 
master repository. If the changes were not incorporated, the effort would be wasted, as it 
would require third-party oversight of the affected, essentially rooted, code. 

It is our opinion that modifications to Android must support the business goals of 
the cellular service companies who sell Android phones. If the modification conflicts 
with that, the modification will never be incorporated into the master repository no matter 
how worthy. Since mesh networks would make metering cellular data challenging, the 
limitations may remain largely unchanged in the Android master repository. 
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a. Manual Intervention Required to Connection to Wifi Networks 

The first step in building this mesh requires Android devices to connect to another 
device programmatically without requiring user input. To implement this, we configure 
an AP and load its connection settings (SSID and key) into a WifiConfiguration variable. 
Then we tell the WifiManager to enable() and reconnect() to that AP. As a security 
precaution, Android will not connect to it until the user visits the Wifi settings dialog and 
sees the connection. Once connected, it will automatically reconnect without user input. 
This automatic reconnection holds true while the WifiConfiguration remains unchanged. 
If we change the WifiConfiguration, then the user must view the settings again before it 
reconnects to the Wifi AP. 

This security feature forces the user to manually open the Wifi Settings dialog 
before the mesh can automatically connect. Requiring user interaction defeats the purpose 
of the automatic configuration. It also defeats one of the core purposes of this project, 
which is to provide an autonomous capability, that is, an automatically-connecting mesh. 

To overcome this limitation, we need a stable WifiConfiguration for devices 
connecting to the mesh. A stable WifiConfiguration requires either a shared static pre¬ 
shared key or using device-specific keys. 


b. Wi-Fi Direct Fixed IP Subnet and Lack of Routing 

As we build out the Discover and WifiConnection classes specified in Chapter III, 
we find that Wi-Fi Direct uses the 192.168.49.0/28 subnet each time it builds a GO AP. 
This static setting causes every link in the mesh to have the same subnet. Also, Wi-Fi 
Direct does not add routing statements to bridge or forward packets between the p2p0 


interface with the wlanO interface as depicted in scenario b) of Figure 22 This lack of 
routing modifications means that Android devices cannot act as mesh routers without a 
workaround. 
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Scenario a) Node B cannot determine which interface (wlanO or p2p0) to open a unicast 
socket on to connect to either Node A or Node C since both networks have the same 
subnet. 

Scenario b): Node B will not forward packets between interface p2p0 and wlanO because 
it lacks routes and forwarding rules. 

Scenario c): Node B filters all inbound Multicast packets on its p2p0 interface. 

Figure 22. Android Devices Failing to Bridge Groups 


Funai, Tapparello, and Heinzelman note this same problem in their paper, titled 
“Supporting Multi-hop Device-to-Device Networks Through WiFi Direct Multi-group 
Networking” (Funai et al, 2017). They offer two solutions for overcoming this problem: 
relay devices and modifying the Android source code. 


First, they add a relay device that connects to two Wi-Fi Direct groups 


simultaneously with its wlanO and p2p0 interfaces depicted in [Figure 23 ,| This relay 
device ferries data between the two groups using a variety of the teeter-totter schemes for 
overcoming the redundant IP subnets (Funai et al., 2017). This technique creates a brittle 
mesh that heals poorly after insertion of nodes. After any change of topology, the mesh 
must re-converge to discover which nodes should perfonn the roles of Relay and GO. 
While the mesh re-converges, routes over any affected area fail. This technique may 
work for delay tolerant networks, but would cause our standard TCP/IP network to fail. 
We reject this technique because it requires devices to play different roles depending on 
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their context, which violates our premise of creating a homogenous mesh network out of 
homogeneous nodes. We also reject it because it introduces significant additional 
instability to the mesh at the link layer. 



Figure 23. Relay Node Ferrying Messages between Two Groups 

Second, they suggest modifying the Android source code to change how Wi-Fi 
Direct sets up the subnets and configures the DFICP service (Funai et al., 2017). They 
successfully modify the Android source code on a version of Android before version 5.0. 
We attempt the same changes on Android 6.0 (Lollipop, API 23) but Android source 
code no longer contains WifiP2pService. In fact, Google rewrote Android 5.0’s Wifi 
networking package, and it no longer offers the same flexibility for modifying the 
WifiP2pService. We downloaded the most recent Android source and tried to replicate 
the changes to the default Wi-Fi Direct configurations without success. We discovered 
that Android, after version 4.4, baked the IP address into the libraries that interface 
between the Androids Java environment and Android kernel. This removed the relatively 
simple method of customizing the IP network settings that Funai et al utilized. 

We find that the Android kernel still responds to ifconfig commands from the 
ADB shell, but Android does not provide an API to control it natively. Soares, Brandao, 
Prior, and Aguiar (2017) successfully get around this problem using reflection to internal 
APIs and root permissions on a Gigabyte Gsmart G1305, a Samsung Nexus S and a 
Samsung Galaxy Tab 10.1 to create 802.11 IBSS (Wifi Ad Floe mobile) connections. 
They build an app called AdHocDroid which controls the device’s interfaces and 
implements an OLSR daemon. They find that each Android device maker uses different 
drivers, which makes their app only work on certain devices. Considering the fragility of 

their approach we decide to not follow their method. 
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While neither of Funai, Tapparello, and Heinzelman’s suggestions worked in our 
case, they did provide us the idea of using Broadcast or Multicast to bridge the groups. In 
the next two subsections, we describe our attempts at bridging the groups. 


c. IPv4 Unicast for Bridging Two Groups 

As we see from above, a homogeneous mesh built using Wi-Fi Direct and Legacy 
Wifi limits us to re-using the 192.168.49.0/28 subnet for every link. Since every link has 
the same IPv4 subnet, we found that Android will not open any Unicast sockets or 
Broadcast IPv4 sockets while the Wi-Fi Direct GO and Legacy Wifi connections are both 
active within the mesh (depicted in Figure 24 ) If we disable the Wi-Fi Direct GO, then 
Unicast and Broadcast become available again. When both links are active, the routing 
table contains entries for both networks making it impossible for Android to detennine on 
which interface to open the socket. Further, Android Unicast and Broadcast socket 
libraries do not support specifying the interface. Thus, IPv4 Unicast and Broadcast are 
not available for bridging groups, leaving us with either IPv4 Multicast or IPv6 for 
transport. 




Figure 24. SINET Node Fails to Open IPv4 Unicast Sockets 


d. IPv4 Multicast for Bridging Two Groups 

After attempting to bridge the wlanO and p2p0 interfaces using IPv4 Unicast and 
Broadcast sockets, we next try using IPv4 Multicast sockets. The IPv4 Multicast libraries 
support specifying the outbound interface. We can successfully send Multicast between 
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the Node A and Node C as depicted in [Figure 25| . Node B (the GO) does not allow 
multicast packets to come up the network stack but filters them at the IP level. Android 
API 23 provides the method WifiManager.MulticastLock() for removing the multicast 
filter from the wlanO interface. Android does not provide a corresponding method for the 
WifiP2pManager class that manages the p2p0 interface. Since the p2p0 interface filters 
multicast packets, we cannot use multicast to bridge multiple groups in our mesh. 


Node B (GO) 



When Node A sends a multicast packet out on interface wlanO, Node B will forward it to 
Node C but will filter it from itself. Wi-Fi Direct filters out multicast traffic. Similarly, 

Wi-Fi Direct does not accept IPv6 connections but will allow IPv6 packets to travel from 
Node A to Node C. 

Figure 25. Multicast Traffic and IPv6 Traffic with Wi-Fi Direct 
e. IPv6 for Bridging Two Groups 

In Android version 6.0, Wi-Fi Direct does not issue IPv6 addresses through its 
DHCP service. When a device connects to a Wi-Fi Direct AP, its wlanO interface only 
shows an IPv6 SLAAC address. On the Wi-Fi Direct device, its p2p0 interface also only 
shows an IPv6 SLAAC address. When a host uses an IPv6 SLAAC address to connect to 
another host in Linux, the host must specify which outbound interface to use. 

We first try running a “ping6 -I wlanO fe80::c2bd:dlff:fe77:b9c6” command from 
Node A to Node B using node B’s p2p0 SLAAC address, with the same topology as 
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depicted in figure 25| . The ping6 command fails to receive any response from Node B’s 
p2p0 interface. We next try a “ping6 -I wlanO fe80::c0bd:dlff:fel6:50cd” command from 
Node A to Node C’s wlanO SLAAC address. This time the ping6 command succeeds, 
thereby proving IPv6 works on the Android devices. 


Next, we attempt to implement IPv6 socket connections in our SINETapp. We are 
unable to create unicast connections to any other device using IPv6 SLAAC addresses in 
Java on Android version 6.0. As we see with the IPv4 unicast, Android attempts to 
detennine the outbound interface for sockets automatically. This automation conflicts 
with the Linux requirement of defining the interface for IPv6 SLAAC connections. 


We next attempt to create IPv6 multicast connections with SLAAC addresses. We 
experience the same filtering as see with IPv4 multicast on the p2p0 interface. Having 
exhausted the possible methods for connecting over IPv6, we determine that IPv6 did not 
provide us any additional capability for bridging two groups in a homogeneous Wifi 
mesh network. 


f. Summary of Practical Limitations 

Our design objective of building a homogeneous Wifi mesh network using only 
Android mobile devices results in an impasse due to practical limitations. First, we are 
unable to connect to the mesh without user interaction for each new connection. Second, 
we find that Wi-Fi Direct utilizes the IP subnet of 192.168.49.0/28 each time it builds a 
new group. It also does not insert the needed routing statements to allow traffic to bridge 
between groups. We attempt to overcome these routing limitations by unwrapping each 
packet and manually forwarding them using an IPv4 unicast, IPv4 multicast, IPv6 
unicast, and IPv6 multicast. None of these approaches allow us to bridge between two 
groups. Thus, we cannot build a homogeneous Wifi mesh network with mobile devices 
running Android version 6.0. 

3. Positive Aspects of SINET’s Design 

In this next section, we explore the positive aspects of our research. While Wi-Fi 
Direct proves a poor choice in its current implementation from the aspect of IP 
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assignment, it does provide |robust security! and [excellent service discovery mechanisms 
We highlight these two areas in the following sections. 


a. Testing SINET’s WPA2 Security 

Once Wi-Fi Direct sets up the GO AP it chooses a random eight-digit upper and 
lower case alphabetic pre-shared key (PSK). The security of the Wifi resides in the 
(26 + 26) 8 = 5.3 x 10 13 possible combinations of PSKs. Using Kali Linux, in a Virtual 
Machine, provisioned with lx 2.8 GHz processor core and 1024 MB of random access 
memory, we brute-force guess PKSs at a rate of 1230.88 PSKs per second. At this rate, 
our Kali Linux Virtual Machine would take 684.5 years on average to guess the WPA2 
PSK. Wi-Fi Direct’s scheme appears sufficiently robust and meets the requirements of 
the Capability Package. 

When we discuss alternate methods later in this chapter, we are no longer 
constrained to Android’s Wi-Fi Direct implementation and can increase the security by 
defining a longer and more complex PSK. 

b. Wi-Fi Service Discovery for Automated Connections 

The Wi-Fi Direct Service Discovery mechanism proves robust and very handy in 
building the automated device detection. We appreciate its reliability and simplicity. 
Passing the PSK in an encrypted packet significantly reduces the requirement for humans 
to type in complex passwords. It also allows devices to detect each other effectively. 

c. Summary of Positive Aspects 

Wi-Fi Direct’s WPA2 security and Service Discovery mechanisms impress us in 
their simplicity, security, and robustness. We highly suggest follow-on non-Android 
centric mesh projects leverage these capabilities. Together they provide a secure way to 
automate device connection configuration. 

4. Summary of Implementation Results 

Through the process of implementing the design prescribed in Chapter III, we 
discovered significant limitations in Wi-Fi Direct with respect to Android version 6.0 that 
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prevented the construction of a homogeneous Wifi mesh network on that platform. We 
discovered fundamental limitations, which included channel utilization and power 
consumption, while running an AP on a mobile device. We also found Wi-Fi Direct 
reuses the same IP subnet every time it constructs an AP on this platfonn. The Android 
version 5.0 and 6.0 re-write of the Wifi module blocks one of the previous workarounds 
for this limitation. Also, we explored four other approaches to bridge Wi-Fi Direct groups 
that proved unsuccessful. These limitations in Android version 6.0 stymied our efforts to 
build a homogeneous Wifi mesh network over Android mobile devices. In the process of 
this research, we found Wi-Fi Direct’s choice of WPA2 PSKs robust, and we found the 
Wi-Fi Direct’s Service Discovery mechanism provides a significant capability. In the 
next section, we suggest two approaches for overcoming infrastructure-less environments 
with secure MANETs. 


B. 


ALTERNATE APPROACHES TO SECURE MANETS 


Since the COTS Android 6.0’s implementation of Wi-Fi Direct makes it 
impossible to create a routable homogeneous Wifi mesh, we next discuss how future 


projects might overcome these limitations. The |IIrst method involvesl creating custom 
kernel modules for Android. The second method alters our constraints and builds a 


homogeneous mesh of “ [helper devices! ” to which mobile devices connect; that is, the 
structure of the mesh is implemented separately from the Android smartphone devices 
that connect to the provisioned network. 


1. Rooted Devices 

Before delving into this section, we believe it is critical to highlight the numerous 
hacked-together Android modifications that litter the Internet. Our naivetes would incline 
us to think that our modification will end up as a glorious revision added into the master 
Android repository. In reality, only the patches that support the business goals of the 
cellular service providers will find traction. If Google does not include a kernel 
modification or patch into the master repository, it will not receive updates. If not 
included, the patch will require significant effort, by a third-party, to keep current as a 
branch, or it will die. 
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With that disclaimer, we think there are two ways to approach this building of a 
secure homogeneous Wifi mesh network with rooted Android devices, that is, Android 
devices where the core kernel has been modified outside Google control. First, implement 
an 802.1 Is Mesh networking kernel module for Android. Second, leverage the prior work 
by Soares, Brandao, Prior, and Aguiar (2017). 

a. 802.11s Mesh Kernel Module 

Building an Android kernel module for 802.1 Is Mesh would require a significant 
amount of work. Our brief exploration of the topic shows very little previous work. Not 
only would the kernel module need to be developed, but a means of controlling it from 
the Android Java environment would be necessary. Soares, Brandao, Prior, and Aguiar 
provide a method for executing shell commands that might help in this effort (Soares et 
ah, 2017). The kernel module would need to incorporate a mechanism for running a 
RADIUS server to satisfy the NSA’s requirement for unique authentication and 
encryption per connection. Such a service would also need to be distributed, as described 
for the DNS service earlier, such that it is readily available throughout the established 
mesh regardless of link failures. 

Building an 802.11s Mesh kernel module for Android would abstract the 
problems of building and maintaining the mesh from the DNS and VPN security layers 
mentioned above in Chapter III. IEEE 802.11s Mesh specifications require hardware 
layer routing within the mesh to provide two virtual LANs (VLAN) to the IP layer. This 
abstraction would increase the modularity of the project. It would also require the VPN 
and DNS to map the mesh themselves, which would duplicate the network discovery and 
mapping messages. The trade-off between modularity and duplication of effort may 
require careful consideration. 

b. Leverage Soares, Brandao, Prior, and Aguiar’s Work 

Soares, Brandao, Prior, and Aguiar’s work provides a mesh over Ad Hoc links as 

well as a mesh-oriented routing protocol (Soares et ah, 2017). A follow-on project would 

need to modify their work to control the Wi-Fi Direct interface. Wifi Ad Hoc mode does 

not meet the NSA’s requirement for unique authentication on each link. A follow-on 
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project would need to also implement a secure peer-to-peer VPN and DNS on top of their 
protocol’s mesh. 

c. Rooted Devices Summary 

Rooting Android allows a developer to access functionality that otherwise is 
inaccessible at the risk of having a device no longer supportable by the Google support 
base. By rooting Android, a future project could successfully build a secure homogeneous 
Wifi mesh. We propose two paths forward but caveat those ways with a strong warning 
about the fragility of developing on a rooted device. The next subsection offers a 
different approach that would avoid these concerns. 

2. Helper Devices 

Since Android version 6.0 blocks multi-hop routing over a homogeneous Wifi 
mesh network, we need to change a core constraint for this project. We suggest changing 
the homogeneous mesh to a heterogeneous network. The core of this network would 
consist of a homogeneous mesh of helper devices connecting over a meshed Wifi 
backhaul as depicted in |Figure 26| . The mesh helper network would control access as seen 
in [Figure 2l\ provide IP routing, and act as a distributed DNS service. The helper devices 
would need at least two antennas to allow the backhaul mesh to run on a separate channel 
from the APs for the end-user devices (EUDs). The EUDs would connect to the helper 
devices and build a p2p VPN on top of it, as depicted in [Figure 30 . 


63 






End User Devices 


End User Devices 


End User Devices 


Helper nodes need to have two antennas to allow one to provide an EUD AP and the 
other for connecting to the backhaul mesh network. 

Figure 26. Example Helper Device Mesh Network 


For access control, the helper mesh will need a RADIUS server, as depicted in 


Figure 27| to satisfy the NSA’s requirement for uniquely keyed WPA2 connections. The 
RADIUS server would validate devices using either a replicated or distributed key-store 
containing all authorized devices’ public keys. Use of the PSK would allow the operator 
to rapidly re-key the mesh. WPA2’s challenge and response mechanism would protect 
against playback attacks. 



Figure 27. WPA2 RADIUS Asymmetric Key Handshake 
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For IP routing, we suggest OLSR routing implemented at the application level. 
Further, we suggest augmenting OLSR to carry the hostname with the IP address of end 
nodes in its routing maintenance messages. Carrying the hostname of the devices would 
allow the helper devices to easily provide a distributed DNS service for the mesh. 


The EUD would run a p2p VPN client that would pull DNS information from the 


helper node’s DNS service, as depicted in [Figure 28 This VPN client would provide the 
second layer of the NSA-required dual layers of encryption. Since each layer must 
provide EUD specific encryption and authentication, we propose the hybrid encryption 
technique as depicted in Figure 2§ as a means of authenticating and encrypting the 
tunneled traffic for the p2p VPN. Our hybrid technique uses the strength of asymmetric 
keys to share the symmetric stream cipher key used for encrypting packets. The 
symmetric stream cipher key provides the efficiency of stream ciphers for bulk 
encryption of the packets. This technique works well for unicast traffic. This concept 
might be modified to enable multicast and broadcast encryption by removing the 
destination’s key from the scheme. 



Q 


DNS Re<juests 


Distributed 
DNS Server 



Mesh 


Figure 28. Helper Device Providing OLSR Routing and DNS Services 
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Figure 29. Example of Hybrid Encryption Scheme for P2p VPN 


Our proposed helper mesh network introduces a challenge in providing a secure 
method for configuring and modifying the PSK and distributed key library not seen in a 
pure homogeneous Will mesh of EUDs. A secure configuration side-channel would be 
required to address this. Wi-Fi Direct and the Service Discovery techniques we discuss in 
Chapter III might offer a means for building this secure connection. 

In this proposed method, we suggest using a homogeneous mesh of helper 
devices. This mesh of helper devices provides distributed and secure AP and DNS. EUDs 
can leverage the helper mesh to operate a p2p VPN. This solution meets the NSA’s 
requirements for dual encryption for wireless network solutions 


66 





































VPN layers 



layers Android EUD Helper node Helper node Android EUD 

Figure 30. Network Stack Flow of EUD Based P2p VPN and Flelper Nodes 
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3. Summary of Alternate Approaches 

In this section, we discussed two ways to overcome the limitations of building a 
homogeneous Wifi mesh network with Android devices. With warnings against the 
fragility of the approach, we suggested the option of gaining root access and extending 
the capabilities with custom kernel modifications. We think that the better approach 
would be to build a mesh of helper devices. 

C. IMPLEMENTATION AND TESTING SUMMARY 

In this chapter, we discussed the fundamental and practical limitations to 
implementing a homogeneous Wifi mesh network with Android 6.0 (Marshmallow), 
API 23 mobile devices. Specifically, we discussed how Wi-Fi Direct provides excellent 
security and discovery features but blocks devices attempting to bridge multiple Wi-Fi 
Direct groups by using the same IP subnet for every Wi-Fi Direct group. Devices 
connected to two Wi-Fi Direct groups cannot open IPv4 or IPv6 unicast sockets. Also, 
the Wi-Fi Direct GO device cannot receive IPv4 or IPv6 multicast packets. We then 
discuss two approaches for overcoming these limitations. First, building a custom kernel 
for Android that provides 802.11 mesh mode. Second, building a mesh using helper 
devices to offload the functions of building a mesh to dedicated devices. Both of these 
techniques hold promise as future work. 


68 



V. SUMMARY AND CONCLUSION 


This research explored how we might enable first responders and military C2 with 
a secure, well-connected, lightweight, and mobile handheld computing device using a 
simple and familiar interface through a secure homogeneous Wifi mesh built with COTS 
Android 6.0 mobile devices. 

In Chapter II, we first examined the stringent encryption requirements for secure 
communication and the current military radios that meet the security requirements. We 
found the current solutions to be expensive and inconvenient. Next, we surveyed wireless 
technologies found in COTs devices and the MANET concepts needed to interconnect 
them: mesh types, MANET routing protocols, and approaches to storing data in 
MANETs. From this survey, we decided to leverage the security, bandwidth, and range 
of Wifi and Wi-Fi Direct with WPA2 to build a secure mesh of Android devices. We 
noted that Android does not support mesh networks or connecting to multiple Wi-Fi 
Direct groups simultaneously, however Wi-Fi Direct provides remarkable service 
discovery and security. 

|Chapter ID outlines our proposed design of building an application to provide a 
secure mobile ad hoc network or MANET. We detail how we might overcome Android’s 
limitations for building a Wifi mesh. We also provide a structure for how to automate and 
secure the mesh in a simple to use application that provides a DNS without centralized 
servers. 

In |Chapter IV , we present the limitations Android 6.0 (Marshmallow) API 23 
impose on implementing a homogeneous Wifi mesh network of mobile devices. The first 
limitation arises from mobile devices containing a single Wifi antenna that restricts other 
devices on the mesh to a single Wifi Channel. Second, a Wi-Fi Direct GO AP introduces 
a significant drain on a mobile device’s energy resources. Third, we found that the 
Android 6.0 API 23’s Wi-Fi Direct implementation restricts devices from building multi¬ 
hop networks. Specifically, by blocking a device connected to two Wi-Fi Direct groups 
from opening IPv4 or IPv6 unicast sockets and Android also restricts a Wi-Fi Direct GO 
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from receiving or sending IPv4 or IPv6 multicast packets over the Wi-Fi Direct interface. 
These limitations make it impossible to build a secure homogenous Wifi mesh on 
Android 6.0 (Marshmallow) API 23 without gaining root pennissions. 


In the second half of |Chapter IVj we considered two approaches for overcoming 
the limitations of using Android 6.0 for building a secure Wifi mesh. First, we explored 
how to enable custom functionality beyond what Android provides by gaining root 
pennissions. While this technique is possible, it introduces significant concerns of 
sustainability outlined in |Chapter IV . Second, we explored using helper devices equipped 
with multiple Wifi antennas for building a secure homogeneous Wifi mesh network. The 
helper network provides Wifi Access Points for mobile devices to join the mesh. To 
connect to the mesh network, the mobile device must authenticate itself with a helper 
node by encrypting the mesh’s pre-shared key with the device’s asymmetric key. To meet 
the NSA’s security requirement all links in the mesh are encrypted using WPA2 and all 
devices connect to each other with a p2p VPN client. The p2p VPN client builds tunnels 
to other devices using dual asymmetric keys and a symmetric key to encrypt and share 
the random tunnel key. Devices on the mesh use a distributed DNS service embedded in 
the routing protocol to find each other. This technique shows promise in reducing the 
energy consumption on the end device while still meeting the NSA’s security 
requirements for the mesh network. It also would allow non-Android devices to join the 
network. 


A. KEY FINDINGS 


Our research set out to discover if Android mobile devices could meet the needs 
of military personnel and first responders in an infrastructure-less environment by 
building a secure homogeneous Wifi mesh network. We discovered that Android 6.0 
mobile devices cannot provide a homogeneous Wifi mesh network. We further examined 
means of overcoming Android’s limitations in providing a Wifi mesh. This section 
contains a consolidated list of the key findings from this research. 




Mobile devices with a single Wifi antenna restrict a homogeneous Wifi mesh 
to a single Wifi channel. A single Wifi channel significantly restricts the 
useable bandwidth of the network when divided among closely located 
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devices. As a result, the number of simultaneous connections is severely 
limited. 




Wi-Fi Direct on Android 6.0 consumes significant energy when active. 


Wi-Fi Direct on Android 6.0 reuses the same IP subnet for every group. When 
associated to two Wi-Fi Direct groups, Android 6.0 cannot detennine on 
which interface to open IPv4 sockets since both interfaces have the same IP 
subnet. Android devices associated to two groups cannot open unicast or 
broadcast sockets to other devices in either group. _ 




Android 6.0’s Wi-Fi Direct interface blocks all IPv4 and IPv6 multicast traffic 
inbound and outbound. Unlike the standard Wifi interface, the Wi-Fi Direct 
interface’s multicast block cannot be removed. 




Android 6.0 IPv6 unicast sockets do not support use of IPv6 SLAAC 
addresses. 




Android 6.0 cannot build homogeneous Wifi mesh networks without gaining 
root pennissions and modifying the underlying Android processes. _ 




Helper devices equipped with multiple Wifi antennas provide a promising 
architecture for building a secure mesh network in infrastructure-less 
environments. 




Using a combination of pre-shared keys and asymmetric keys with a RADIUS 
server meets NSA requirements for unique Wifi authentication per device. 




Using a system of dual asymmetric keys and a symmetric key to build a VPN 
tunnel on top of a WPA2 encrypted Wifi satisfies the NSA’s requirement for 
double encrypting Wifi links. _ 


These results should help guide future work toward the goal of building secure 
Wifi mesh networks to operate in infrastructure-less environments. In the next section, 
we discuss promising research areas that may leverage our findings. 

B. FUTURE WORK 

This section provides a brief list of research questions that build on our research. 

• How to securely manage asymmetric keys in an infrastructure-less 
environment? How to distribute a new public key and make sure it replicates 
to all desired devices and how to revoke compromised keys? Our research 
indicates distributed hash tables provide a promising means for distributing 
and tracking keys. 
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• How to implement a distributed p2p DNS server? Any infrastructure-less 
mesh network or MANET will need a p2p DNS service for finding other 
devices. Our research indicates that close integration with the routing protocol 
provide the most promising means for maintaining the p2p DNS records. 

• How to build a p2p VPN? Our research proposed a method for building a p2p 
VPN network. How might a p2p VPN handle multicast and broadcast 
messages? 

• What is the suitability of Wifi in contested environments? Contested 
environments may consist of an adversary actively jamming, direction 
finding, or attempting to discover information from the Wifi signals. Of these 
activities, the danger of direction finding may provide the largest danger since 
it allows an adversary to target friendly forces with kinetic weapons. 
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